System and method for detecting fraudulent transactions

ABSTRACT

A system for detecting fraudulent transactions is disclosed. The system breaks the transaction down into its component parameters. A first score is computed depending on the propensity of the transacted commodity to be involved in fraud. A second score is computed as a function of the authentication of the remaining parameters of the transaction. A total fraud score is computed from the first score and the second score and compared against a fraud threshold to determine the likelihood of the transaction being fraudulent.

BACKGROUND

[0001] Everyday, millions of commercial transactions take place betweencustomers and vendors of goods and/or services (“commodities”). Many ofthese transactions are consummated face to face in physical retailestablishments, over the telephone, such as with catalog based vendors,through the Internet with e-commerce based vendors or through somecombination thereof.

[0002] Each of these transactions involves the exchange of value, suchas cash/currency, bank draft/check or credit, for commodities. One othercommonality that all of these transactions share is the potential thatthe customer making the transaction is acting fraudulently to acquirethe commodities from the vendor.

[0003] Fraud often occurs when the customer knowingly utilizes some formof value, such as a bank draft/check or credit card that has no value ordoes not belong to the customer. For example, a customer writes a checkknowing there are no funds to back up that check or utilizes afraudulently obtained or stolen credit card. While fraudulenttransactions only make up a small percentage of the total number oftransactions completed at any given time, the amount of revenue and/orresources lost due to fraud is substantial.

[0004] Vendors of goods and services rely on a number of differentmethods to detect fraudulent transactions. Some rely on the frauddetection systems of third party credit card processors or third partycheck verification systems to determine if the customer is trying tocommit fraud. Other vendors rely on internal fraud detection systems. Ineither case, it is preferable to detect the fraudulent transactionbefore the customer receives the commodities, prevent the loss to thevendor in the first place and reduce or eliminate the expense ofresources devoted to attempting to recover those commodities and/orfinancial compensation.

[0005] An important characteristic of these fraud detection systems istheir error rate. Errors include false negative responses, where afraudulent transaction goes undetected and false positive responses,where valid transactions are mis-flagged as fraudulent. A high falsenegative rate indicates that the system is not performing its intendedfunction and results in continued losses to the vendor due to fraud. Ahigh false positive rate costs the vendor in potentially lost sales andlost resources in further investigating and validating the mis-flaggedtransactions.

[0006] One typical fraud detection system functions by analyzingparameters of the transaction and attempting to identify characteristicswhich indicate that the transaction is fraudulent. This system breaksdown the transaction into a few select component data parameters andsingle variable relationships. Points are assigned to eachparameter/relationship based on the information it represents andwhether it matches with known data. If the number of points of any oneparameter/relationship exceeds a pre-determined threshold, potentialfraud is indicated. Alternatively, the points of all of theparameters/relationships are summed to create a total score and thenthat total score is compared to a threshold. If the total score exceedsthe threshold, fraudulent activity may be indicated within thetransaction. An exemplary fraud detection system utilizing singleparameters or relationships to identify a primary fraud characteristicis shown in more detail in U.S. Pat. No. 6,029,154, entitled “METHOD ANDSYSTEM FOR DETECTING FRAUD IN A CREDIT CARD TRANSACTION OVER THEINTERNET” to Pettitt.

[0007] Another fraud detection system utilizes a more complex predictivemodel, such as a neural network or other form of model which utilizesself-learning of relationships among variables from historicaltransaction data. This system uses these complex models to analyze thetransaction and predict whether or not the transaction is potentiallyfraudulent. The model is able to automatically correlate relationshipsamong all of the parameters of the transaction to each other, and notjust the single variable relationships of the above detection system. Anexemplary fraud detection system utilizing these self-learning models isshown in more detail in U.S. Pat. No. 5,819,226, entitled “FRAUDDETECTION USING PREDICTIVE MODELING” to Gopinathan, et al. Self-learningbased systems are complex, difficult to develop and require significanttraining and maintenance to maintain accuracy.

SUMMARY

[0008] The present invention is defined by the following claims, andnothing in this section should be taken as a limitation on those claims.By way of introduction, the preferred embodiments described below relateto a method for detecting fraudulent transactions between a customer anda vendor. The method includes receiving a plurality of transactionparameters from the vendor, where the plurality of transactionparameters represents at least one transaction for at least onecommodity between the customer and the vendor. A first score is computedas a function of each commodity involved in the transaction. A secondscore is computed as a function of each of a first one or more of theplurality of transaction parameters. A fraud score is computed based onthe first and second scores. The transaction is indicated to bepotentially fraudulent if the fraud score exceeds a first pre-determinedthreshold.

[0009] The preferred embodiments further relate to a fraud detectionprocessor. The processor includes a receiver operative to receive aplurality of transaction parameters from a vendor, where the pluralityof transaction parameters represents at least one transaction for one ormore commodities between a customer and the vendor. The processor alsoincludes a first score processor coupled with the receiver and operativeto compute a first score as a function of each of the one or morecommodities. In addition, the processor includes a second scoreprocessor coupled with the receiver and operative to compute a secondscore as a function of each of a first one or more of the plurality oftransaction parameters. Further, the processor includes a fraud scoreprocessor coupled with the first and second score processors andoperative to compute a fraud score based on the first and second scores.Finally, the processor includes fraud determination logic coupled withthe fraud score processor and operative to compute a determination ofwhether the at least one transaction is potentially fraudulent based ona comparison of the fraud score and a first pre-determined threshold andfurther operative to indicate this determination to the vendor.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010]FIG. 1 depicts a block diagram of an exemplary commercialtransaction utilizing the preferred fraud detection system.

[0011]FIGS. 2A & 2B depicts a flow chart detailing a first embodiment ofa preferred fraud detection system.

[0012]FIGS. 3A & 3B depicts a flow chart detailing a second embodimentof a preferred fraud detection system.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS

[0013] The disclosed fraud detection system is easily maintained andupdated and has a low error rate. Further, the disclosed system ismodular, being able to be sold and/or provided, in whole or in part, asa service or product to one or more vendors. It will be appreciated thatthe system, as a service or product, may also be embodied as hardwareand/or software and packaged, in whole or in part, as a fraud detectionprocessor. The preferred fraud detection system or processor iscomprised of a number of component parts as described below. One or morecomponents of the system or processor may be deployed as part of avendor's internal transaction processing system while the remainder ofthe system or processor is operated by an entity, external to, and incommunication with the vendor.

[0014] In one embodiment, the entire system resides internally as a partof, or coupled with, the vendor's order processing system in compliancewith all of its interfaces and gateways. Herein, the phrase “coupledwith” is defined to mean directly connected to or indirectly connectedwith through one or more intermediate components. Such intermediatecomponents may include both hardware and software based components.

[0015] Alternatively, most of the fraud detection processing isoffloaded to a consumer information provider. Where the consumerinformation provider is an entity external to the vendor, costs,maintenance, storage and processing considerations are alleviated forthe vendor. In addition, centralization of the fraud detection processallows multiple vendors to pool information resources thereby enhancingthe detection of fraud.

[0016] Further, in yet another alternative embodiment, the entire systemresides externally to the vendor and in communication with the vendor'sorder processing system and is provided, as a “black box” service forexample, by the external entity (i.e. transaction parameters aretransmitted to the external entity and the external entity returns afraud indication result). It will be appreciated that the alternativepreferred embodiments disclosed herein relate to alternate divisions ofthe system's components between the vendor and the external fraudprocessing entity and that all embodiments of the disclosed frauddetection system are contemplated no matter how the division of itscomponent parts is made.

[0017] To support multiple vendors, the system is configurable toaccount for the varying transactional characteristics of eachparticipating vendor, allows each participating vendor the ability toindividually re-configure the system to reduce error rates and permitseach participating vendor to provide internal statistical, demographicand historical transaction data and/or have access to such data fromother vendors (participating or not) to enhance the detection of fraud.

[0018]FIG. 1 shows an exemplary transaction 100 between a customer 102and a vendor 106. The transaction 100 comprises the purchase of acommodity 112 from the vendor 106. Herein, a commodity 112 is a goodand/or service or anything else purchased or traded for value. Thecustomer 102 desires the commodities 112 and the vendor 106 provides thecommodities 112. In one embodiment, the customer 102 is another vendor.

[0019] To complete the transaction 100, the customer 102 interfaces withthe order processing component 104 of the vendor 106, orders 110 acommodity 112 and provides payment information. The vendor 106 processesthe order 110, accepts the payment and delivers 114 the commodity 112 tothe customer 102.

[0020] The transaction 100 can occur in one or more of many differentenvironments. For example, the transaction 100 occurs in a retailestablishment between a customer 102 and a cashier (the order processor104) working for the vendor 106. Alternatively, the transaction occursbetween a customer 102 and a catalog based vendor 106 using a telephoneorder processing system 104 (live operator, automated or a combinationthereof) or between a customer 102 and an electronic commerce(“e-commerce”) based vendor 106 using an Internet, network or wirelessbased order processing system 104. The order processor 104 may even be avending machine, including a machine used to dispense gasoline. Theorder processing system 104 may be manual, automated or a combinationthereof.

[0021] Where the customer 102 attempts to use a credit form of payment,such as a credit card, debit card or bank draft/check, there is anopportunity for defrauding the vendor 106. In such cases, it ispreferable to detect such fraudulent activity before the commodity 112is delivered to the customer 102. Early detection prevents loss ofrevenue or resources by the vendor 106.

[0022]FIG. 1 further shows a fraud detection system 108 which interfaceswith the order processing system 104 of the vendor 106 in order todetect fraudulent activity on the part of the customer 102. The system108 is capable of determining whether or not the transaction 100 ispotentially fraudulent while the transaction 100 is still pending,before the commodities 112 have been delivered to the customer 102.Alternatively, the system 108 is capable of analyzing the transaction100 at a later time to determine whether the payment was potentiallyfraudulent. Both real-time processing and batch processing arecontemplated.

[0023] The fraud detection system 108 receives transaction parameters116 from the vendor's 106 order processing system 104. The transactionparameters 116 represent the pieces of information which make up thetransaction 100. Exemplary transaction parameters 116 include thecustomer's name, address and telephone number, the identity of thecommodity being transacted (also known as a “Stock Keeping Unit” or“SKU” number) and the information related to the form of payment beingused such as a credit card number or checking account number. A SKU isunique identifier code which identifies a particular commodity. Otherparameters 116 may include an alternate shipping address to account fora customer 102 who places an order and has it shipped to an alternateaddress, such as for a gift.

[0024] These transaction parameters 116 may be vendor 106 specific orgeneric to all vendors 106. Some transaction parameters 116 are based onthe nature of the order processing system's 104 requirements to processa given order. For example, a vendor 106 which transacts in productswhich are not delivered (such as a service), may not collect a shippingaddress and therefore would not collect this particular transactionparameter 116. Further, e-commerce based vendors 106 may have access toadditional parameters 116 such as Internet Protocol addresses, domainaddresses or electronic mail addresses. The preferred embodimentsdisclosed herein are designed to account for the different transactionparameters 116 collected by or available from different vendors 106 andare capable of being configured to account for the availability orunavailability of transaction parameters 116 in the determination offraud. Table 1.0 (See below) gives a non-exhaustive list of thetransaction parameters 116 of the preferred embodiments.

[0025] The fraud detection system 108 accepts the transaction parameters116 from the order processing system 104 and analyzes those parameters116, as discussed below in more detail. The fraud detection system 108provides a result or signal 118 to the order processing system 104signifying whether or not the analyzed transaction parameters 116indicate that the transaction 100 is likely fraudulent. In oneembodiment the result or signal 118 is a binary indicator of fraud or nofraud. Alternatively, the result or signal 118 may be numeric or otherdata indicating the likelihood of fraud, for example, as compared to afraudulent value scale. The order processing system 104 is then able toaccount for that result or signal 118 in the processing of thetransaction 100. If the transaction 100 is still pending, the orderprocessing system 104 may pass off the transaction 100 to a manual orautomated investigation system, terminate the transaction 100 before thecommodities 112 are shipped or delivered 114 or demand furtherinformation or an alternative form of payment from the customer beforeshipping or delivering the commodities 112. Alternatively, the orderprocessing system 104 may utilize internal fraud detection systems todouble-check or override the fraud indication signal 118 from the frauddetection system 108. If the transaction 100 has already been completedand the commodities 112 have been shipped to the customer 102, the fraudindicator signal 118 may be used by the order processing system 104 toinstitute loss mitigation or recovery measures such as recalling theshipped commodities 112 back from the shipping agent or handing over thetransaction to an internal or external investigation/collections entity.Transactions 100 determined to be potentially fraudulent ornon-fraudulent may also be updated into the appropriate negative(described in more detail below and in FIG. 2B) or positive database(described in more detail below and in FIG. 2A) for use in processingand preventing losses from later transactions 100 by the same customer102.

[0026] First Embodiment

[0027] Referring now to FIG. 2A, there is shown a flow chart depicting afirst embodiment of a fraud detection system 108. Internally to thevendor 106, the order processing system 104 receives a transaction 100and initiates the fraud detection process. The fraud detection system108 receives initial transaction parameters 116 from the orderprocessing system 104 (Block 202).

[0028] The system performs a payment authorization check (Block 204).This check involves contacting either an external credit card issuingcompany or third party check verification service. Alternatively,internal checks are performed for vendor issued credit accounts. Theexternal issuing company or authorization service performs anauthorization process on the transaction 100, as is known in the art.This authorization process typically catches stolen credit cards orchecks which have already been reported to the issuing company. Further,the authorization process indicates whether the customer has exceeded acredit limit or available funds.

[0029] Alternatively, for credit card transactions, the authorizationcheck includes Address Verification checking (“AVS”), Card VerificationValue Checking (“CVV2”), other fraud detection processes now or laterdeveloped by credit card issuing or authorization companies, orcombinations thereof. AVS checking performs an additional check, beyondverifying funds and credit card status, to ensure that elements of theaddress supplied by the customer 102 match those on record with theissuing company. AVS checks can return results indicating that data isunavailable, or that there is a mismatch or a total or partial match.AVS checking can be repeated with manually tweaked addresses and/ornames to correct misspellings, incorrectly specified billing addresses,and other customer service/order entry mistakes.

[0030] CVV2 checking determines whether or not the customer 102 isactually in possession of the physical credit card by asking for anidentification code imprinted only on the card in a manner which doesnot get reproduced by credit card imprinting or swipe machines. If theauthorization check fails, the transaction is stopped immediately.Otherwise, the processing further continues. However, customers whocommit fraud often utilize methods which avoid being detected bystandard payment authorization techniques. For example, the customer 102intercepts credit cards along with the associated address information,in the mail and uses the credit cards before the cards are reportedstolen to the issuing company. Further, these standard paymentauthorization techniques may fail to work with internationallyoriginated transactions 100.

[0031] The transaction 100 is also checked to see if the value of thecommodities 112 being purchased is greater than a predeterminedthreshold amount 208 (Block 206). A vendor 106 may determine thattransactions 100 whose total value is less a particular threshold areless likely to be fraudulent. Low value transactions 100 are bypassedfrom further fraud processing to avoid wasting resources, and thetransaction 100 is accepted (Block 230). The pre-determined threshold208 is vendor 106 specific or generalized for multiple vendors 106 andvendors 106 may adjust their threshold 208 periodically. Each vendor 106may experience more or less fraud for commodities with differing values.In addition, the pre-determined threshold may be dynamically adjusted toaccount for other transaction parameters 116 and the results of otherfraud detection algorithms (as discussed below). An exemplarypre-determined threshold value is $ 100.00.

[0032] If the value is greater than the pre-determined transactionamount threshold, transaction parameters 116 of the transaction 100 arecompared against a positive database 212 (Block 210). The positivedatabase 212 maintains customer 102 identity information, including oneor more of the transaction parameters from past transactions which havebeen determined to be non-fraudulent. Such customer identity informationmay include the customer name, credit card number, checking accountnumber, address or combinations thereof. This database 212 accounts forcustomers 102 who have a known good relationship with a vendor 106 butoften have their transactions 100 flagged as fraudulent by frauddetection system 108 for other reasons such as a high transactionamount, shipping to a high risk zip code or an unusually high frequencyof orders (“velocity”). As the nature of such positive information islikely highly confidential, such positive databases 212 and comparisons(Block 210) are preferably completed internally to said vendor 106. Inaddition, this positive data tends to be vendor specific, i.e. justbecause a customer has not committed fraud at one vendor does notnecessarily mean they are not likely to commit fraud at another vendor.If the current customer 102 is found in the positive database 212, thetransaction 100 is bypassed from further processing, and the transactionaccepted (Block 230). Otherwise the fraud detection system continues itsanalysis (Block 214). In alternative embodiments, the positiveidentification is used to decrease the likelihood of a false positiveresult from the fraud detection system.

[0033] In order to further analyze the parameters 116, the form ofpayment which the customer 102 is using is determined (Blocks 218, 220).Credit card based transactions 100 have different parameters 116 thanbank draft or check based transactions 100. In alternative embodiments,the transaction 100 environment is determined, i.e. whether thetransaction 100 is originating from a retail establishment, a telephoneordering vendor or an e-commerce based vendor.

[0034] In one embodiment, the transaction parameters 116 are formattedand transmitted to a consumer information provider 224 who completes thefraud detection process (Block 222). The consumer information provider224 is preferably an entity external to the vendor 106 and is preferablya fraud detection service provider who provides fraud detection servicesto multiple vendors 106. Alternatively, the consumer informationprovider 224 is another vendor 106 which sells excess fraud processingcapacity as a service to other vendors 106 or the consumer informationprovider 224 is an internal part of the vendor 106 (e.g. part of orcoupled with the order processing system 104). The consumer informationprovider 224 returns a signal 118 indicating whether or not thetransaction 100 is likely fraudulent (Block 226). If the transaction islikely non-fraudulent (Block 228), the transaction is accepted (Block230) and the commodities 112 are delivered. If the transaction 100 islikely fraudulent (Block 228), the system performs the desired vendorspecific action to combat this potential fraud (Block 232). For example,the system cancels the transaction and prevents delivery of thecommodities 112 to the customer 102, or the transaction is flagged forfurther review.

[0035] Referring now to FIG. 2B, there is shown a flow chart depictingthe fraud detection processing undertaken by the consumer informationprovider 224. The consumer information provider 224 receives the requestto determine the fraudulent status of a transaction 100 and theaccompanying transaction parameters from the vendor 106 (Block 302).This request is transmitted by telephone, network, Internet or othercommunication medium. Initially, the transaction 100 is assumed to benon-fraudulent and subsequent processing determines if the transactionis likely fraudulent (Block 304). In alternative embodiments, theinitial assumption is that the transaction is likely fraudulent andsubsequent processing attempts to disprove this.

[0036] The consumer information provider 224 first computes a fraudmultiplier for the transaction 100 (Block 306). The fraud multiplier isa score based on the value of the transaction parameters 116 and whetherthe transaction parameters authenticate against databases 308, 310, 312of known information. These databases 308, 310, 312 include a customerinformation database 308, a negative account database 310 and a negativeaddress database 312. Generally, these databases 308, 310, 312 containspecific customer and consumer information, statistical data andhistorical transaction data known to the participating vendors 106, 316,318.

[0037] The customer information database 308 is a collection ofinformation about the customers 102 of each of the vendors 106, 316,318. There will be a separate database 308 for each vendor 106, 316, 318since such customer information is typically only relevant to theparticular vendor that the customer belongs to. Alternatively, bycollecting the information from each participating vendor 106, 316, 318together, a broad database is provided to all of the vendors 106, 316,318, enhancing the accuracy of the fraud detection system and reducingerror rates. Further, where the consumer information provider 224 is aninternal function of the vendor 106, or due to privacy issues, this datamay represent only one vendor's customer information. The customerinformation database 308 preferably includes data representinginformation about existing customers such as the customer name, address,how long the customer has been a customer and information about one ormore of their past transactions. In the e-commerce environment, thisdatabase 308 may further contain information such as the customer'sInternet Protocol Address, e-mail address or domain address.

[0038] The negative account database 310 and the negative addressdatabase 312 include information about past transactions that are knownto have been fraudulent. The negative account database 310 includescredit card account numbers and/or checking account numbers used in pastfraudulent transactions. The negative address database 312 includescustomer, card holder, or shipping addresses previously involved infraudulent transactions. The data in the databases 310, 312 is providedby the participating vendors 106, 316, 318, financial institutions orother entities. The negative databases 310, 312 are provided as arecognition of the fact that a fraud committed or attempted against onevendor 106, 316, 318 is generally relevant information to all vendors106, 316, 318. In this way, one vendor 106, 316, 318 benefits from thenegative experience of another vendor 106, 316, 318.

[0039] The databases 308, 310, 312 may further include the positivedatabases 212 used in Block 210 of FIG. 2A so that this comparison maybe performed by the fraud detection system 108. Alternatively, eachparticipating vendor 106, 316, 318 has access to the other vendors'positive transaction history data where it is relevant across vendors106, 316, 318. Where positive databases are included, the positive datais used by the fraud detection system 108 as a factor in the fraudmultiplier computation and not to override the fraud determinationprocess as is shown in FIG. 2A. Alternatively, where such positive datais relevant across vendors, it may be used to bypass further fraudprocessing and approve the transaction. Additional databases comprisingpublicly available data such as credit histories or bankruptcyinformation, whether internal to the fraud detection system or providedby third party entities, may also be used to augment one or more of thedatabases 308, 310, 312. Additional databases containing non-publicinformation such as proprietary internal data from other vendors orother private entities, whether internally provided or provided by athird party entity, may also be included.

[0040] In addition to the above databases 308, 310, 312, a fraudmultiplier point database 314 is also provided. The fraud multiplierpoint database 314 includes data representing the transaction parameters116 that a participating vendor 106 provides with each frauddetermination request. This data may be different or specific for eachparticipating vendor 106, 316, 318 depending upon each vendors 106transaction environment and fraud experience. In one embodiment, thedata is stored in a common database 314 or alternatively, each vendor106, 316, 318 may have their own database 314. For example, the customerstatus transaction parameter can be defined by each vendor 106, 316,318. For vendors 106, 316, 318 that sell exclusive memberships but stillallow non-members to transact, the customer status parameter mayindicate a member or non-member status. Alternatively, the customerstatus parameter indicates a preferred status or how good of a customerthat vendor 106, 316, 318 feels the customer is, poor, fair, good orexcellent depending on the amount they buy or their frequency ofreturns, etc. For each transaction parameter 116, a corresponding pointvalue is provided which represents the number of points to be computedinto the fraud calculation (described in more detail below) if thatparticular transaction parameter authenticates or doesn't authenticatein one of the databases 308, 310, 312. The point values are determinedat the discretion of each vendor 106 depending on their individualbusiness environments and point values for the same transactionparameters 116 may vary from vendor 106 to vendor 106. For example, somevendors 106, 316, 318 may experience more fraud from particulargeographic areas than other vendors 106, 316, 318. These vendors 106,316, 318 then may assign higher point values to address matches with theparticular zip codes covering those geographic areas then might beassigned by another vendor 106, 316, 318.

[0041] Some transaction parameters 116 are essentially Boolean variableswhich have a True value if the value of the parameter can beauthenticated against one of the databases 308, 310, 312. In this case,the parameter 116 is assigned points based on whether it is true orfalse. In addition, some transaction parameters 116 are assigned pointsbased on the value of that parameter 116. For example, the transactionparameter 116 representing the total value of the transaction 100 isassigned a specific number of points as a function of this value (e.g.0.5 points per $100 of value).

[0042] Alternatively, the points assigned to a particular transactionparameter 116 are dependent on the values of one or more othertransaction parameters. For example, a transaction parameter 116representing the credit card number velocity is assigned points based onthe frequency of use of that credit card number (itself anothertransaction parameter 116). A velocity is a frequency of use over aspecified period of time or a specified number of transactions. Velocitychecks are done for transaction 100 counts (“count velocity”) as well asamounts (“amount velocity”), i.e. the frequency of transactions 100 of aparticular value. The velocity checks are performed against customer 102identities, credit card account numbers, checking account numbers andaddresses, cardholder, ship-to or otherwise (e.g., the frequency ofaddress changes). Other relationships can also be captured by the pointassignments. For example, depending on the value of one or moretransaction parameters 116, one or more other transaction parameters 116may be further computed with a weighting to increase or decreasesignificance to the overall fraud determination. Generally, points orpoint and parameter relationships are assigned and/or computed for aparticular transaction parameter 116 as a function of that parameter's116 relationship to fraudulent transactions. (i.e. whether a particularvalue of a parameter 116, or relationship among parameters 116, islikely to indicate fraud or not). For example, in one embodiment, thepoint values for the transaction velocity parameter 116 are adjustedbased on geographic dispersion of the locations from which each of thetransactions, included in the velocity calculation, were initiated. Thisaccounts for the likelihood of the customer 102 physically being presentat all of those locations at the times when the transactions 100 wereinitiated. An exemplary fraud multiplier point database 314,corresponding transaction parameters 116 and points for a particularvendor 106, is shown in Table 1.0. TABLE 1.0 TRANSACTION PARAMETERPOINTS Positive Database match −5.00 Negative Database (this vendor)match +10.00 Negative Database (other vendor) match +8.50 Not shippingto card holder address +0.50 Shipping to card holder address −1.00 Notshipping to customer address +0.50 Shipping to customer address −1.00Shipping to Freight forwarder +1.00 Third party address verification(AVS) ok −1.00 Third party address verification (AVS) partial ok +2.50Third party address verification (AVS) not ok +5.00 Customer Svc. Rep.Suspects fraud +5.00 High risk zip code +1.50 Telephone order +0.25Total transaction amount +0.50/$100 Air shipment +0.50 Customer duration−0.05/year Customer status = excellent −1.00 Customer status = good−0.25 Customer status = fair +0.25 Customer status = poor +1.00 Creditcard amount velocity exceeded +0.50 Credit card count velocity exceeded+0.50 Customer amount velocity exceeded +0.25 Customer count velocityexceeded +0.25 Ship-to address amount velocity exceeded +0.50 Ship-toaddress count velocity exceeded +0.50 Card Verification Value (CVV2)mismatch +0.50 Card Verification Value (CVV2) match −1.00

[0043] The databases 308, 310, 312, 314 are preferably updatedperiodically. For example, a batch update process is used from eachparticipating vendor 106. Alternatively, the databases 308, 310, 312,314 are updated in real time as each participating vendor 106 acquiresthe relevant data. These updates occur automatically or manually. Thenegative databases 310, 312 are updated by the participating vendors106, 316, 318 with transactions 100 which are verified by the vendor106, 316, 319 as being fraudulent. Records are removed from the negativedatabases 310, 312 when it is determined that the fraudulentindicativeness of the stored information is no longer accurate. In oneembodiment, this occurs only after a manual review indicates that therecord was entered into the negative databases 310, 312 in error or thecustomer's or address' fraudulent status has changed. The customer'sfraudulent status may change, for example, after a specified time periodhas elapsed in which there has been no further fraudulent activity bythat customer. An address' fraudulent status may change if it isdetermined that the previous occupants, who perpetrated the originalfraud, have moved and new customers now live at the address. Inalternative embodiments, records are removed from the negative databases310, 312 automatically based on pre-determined rules such as a definedperiod of non-fraudulent activity or through a combination of automatedprocesses and manual review.

[0044] The fraud multiplier for the transaction is preferably computedby first determining the points for each transaction parameter 116, asdiscussed above. To compute the fraud multiplier, the points determinedfor each transaction parameter 116 are summed to compute a total score(Block 306). Alternatively, other mathematical formulae may be used tocompute the fraud multiplier. It is preferable that a mathematicalcomputation be used which is statistically designed to minimize theoverall error rate for the fraud detection process.

[0045] Once the fraud multiplier has been computed, the fraud detectionsystem next computes the SKU points for the transaction (Block 320). Aswas discussed above, a SKU is a unique identifier code which identifiesparticular commodities involved in transactions 100. Each commodity hasa unique SKU. Each SKU is associated with a point value indicating thatparticular commodity's propensity to be the subject of fraud. For eachparticipating vendor 106, 316, 318, an associated SKU point database 322contains points for the SKU's of the commodities which the particularvendor trades in. The SKU points for the transaction 100 is computed bysumming the individual SKU points for each commodity involved in thetransaction. The sum of the SKU points (i.e. the minimum SKU point sum)is at least 1. This prevents a transaction 100 with a high fraudmultiplier but involving SKU's with no associated points (i.e., SKU'swith very low fraud potential) from attaining a fraud score of 0 (e.g.,where a customer purchases 1000 tubes of lipstick). Where more than oneof the same commodity is being purchased, the SKU points for each isincluded or alternatively, that commodity may only be counted once.Alternative mathematical formulae may also be used such as diminishingor increasing point values or dynamic point values. For example, thelarger the quantity ordered of any one product, the higher the pointsfor that product (i.e., where 500 lipsticks are ordered, the first 100each have 0 points, the next 100 each have 10 points, the next 100 eachhave 20 points, etc.) to allow for the possibility that orders of largequantities of any one product are more likely to be fraudulent. However,the mathematical computation used is statistically designed to minimizethe overall error rate for the fraud detection process. An exemplary SKUpoints database 322 showing SKU's and associated point values for aparticular vendor 106 is shown in Table 2.0. TABLE 2.0 SKU POINTSDESCRIPTION XX001 +10 OFFICE CHAIR-LEATHER XX002 +10 FAX MACHINE XX003+10 CORDLESS PHONE-900/DK/CID XX004 +10 PLAIN PAPER FAX XX005 +10CORDLESS PHONE-900/2LINE/CID XX006 +10 CORDLESS PH-900/2LINE/CID/TAXX007 +10 COMM. BREWER W/COFFEE XX008 +40 STEREO SYSTEM XX009 +20 CDCHANGER/12 CAP XX010 +40 CAMCORDER VHS-C XX011 +10 BUTCHER BLOCK CARTXX012 +10 RED DEVIL GRILL XX013 +10 PRESSURE COOKER XX014 +10 SECURITYAUTO-DIALER XX015 +10 CD RACK XX016 +15 SECURITY CAMERA XX017 +10COCKTAIL TABLE XX018 +10 END TABLE XX019 +10 SOFA TABLE XX020 +10LOVESEAT-FLORAL XX021 +10 SOFA-FLORAL XX022 +15 COMPACT STEREO KEVLARSPE XX023 +15 COMPACT COMPONENT SYSTEM XX024 +15 COMPACT COMPONENT DOLBYXX025 +40 DVD PLAYER XX026 +10 TREADMILL/0-10MPH XX027 +20 TV 1.6″ XX028+10 CAMERA XX029 +15 RACK SYSTEM XX030 +20 4HD VCR

[0046] A total fraud score is computed from the fraud multiplier and theSKU points computed for the transaction (Block 324). The total fraudscore is computed by multiplying the SKU points by the fraud multiplier.Alternatively, other mathematical computations may be used. The fraudscore computation balances the SKU points vs. the other transactionparameters and is statistically designed to minimize the overall errorrate for the fraud detection process. Since points can be subtractedfrom the fraud multiplier for positive transaction characteristics, thefraud score can be a negative number indicating that fraud is extremelyunlikely.

[0047] The total fraud score is compared with a fraud score threshold328 (Block 326). The fraud score threshold indicates the degree ofpotentially fraudulent behavior that indicates that the transaction 100is likely fraudulent. Each participating vendor 106, 316, 318 mayprovide a fraud score threshold. An exemplary fraud score threshold is50 points. Alternatively, multiple fraud score thresholds or a fraudscore range are provided indicating a degree or range of fraudulentlyindicative behavior. In addition, the fraud score threshold may be adynamic value, automatically adjusted based on the values of one or moreof the transaction parameters 116 or SKU's of the commodities 112involved. The dynamic fraud score threshold compensates for thoseparameters which do or do not indicate a substantial likelihood of fraudand may unbalance the computation.

[0048] If the fraud score is less than or equal (or alternatively justless than) to the fraud score threshold (Block 326), the consumerinformation provider 224 returns an indication back to the vendor 106that the transaction is likely non-fraudulent (Block 338). If the fraudscore is above the threshold, the consumer information provider 224returns an indication that the transaction 100 is likely fraudulent. Thereturned indication may be a Boolean flag (i.e. likely fraudulent ornot) or a confidence score related to the likelihood of the transaction100 being fraudulent (e.g., “0”, meaning fraud unlikely, to “9”, meaningfraud extremely likely)

[0049] Alternatively, subsequent processing ensures that non-fraudulenttransactions 100 are not mistakenly indicated as fraudulent. Thetransaction 100 is further checked against other consumer informationdatabases 332 (Block 330). These other consumer information databases332 are typically fee based and include proprietary databases of theconsumer information provider 224 as well as third party public andnon-public information sources. Access charges to these databases 332are usually based on the nature of the database 332 and the nature ofthe authentication query or lookup being performed. For example, theremay be a fixed fee charged for each address verification query. Thesedatabases 332 are alternate databases to the databases 308, 310, 312used in the fraud multiplier computation (Block 306). Matches among thetransaction parameters 116 and these alternative databases 332 can beused to diminish the likelihood that the current transaction 100 isfraudulent. It is preferred that these databases 332 be used tosupplement the fraud determination process to minimize the externalcosts in accessing fee based data. In addition, some vendors 106 mayprefer to supplement their fraud determination with more or fewer checksagainst the databases 332, depending on the amount of access chargesthey are comfortable incurring versus the added benefit to thedetermination of fraud.

[0050] If it is determined that the check of the alternate databases 332has made it unlikely that the current transaction is fraudulent (Block334), a non-fraudulent indicator is returned to the vendor 106 forfurther processing as described above (Block 338). Otherwise anindicator indicating that the current transaction 100 is likelyfraudulent is returned to the vendor 106 (Block 338). In one embodiment,the customer address, card holder address and ship-to address are allverified against databases 332. If all three match, the fraud score isoverridden and the transaction is approved. Alternatively, a lessstringent match is required or other parameters are verified in place ofor in addition to the addresses. In yet another alternative embodiment,the authentication results from the databases 332 are, themselves,assigned point values. Utilizing these point values, the fraud score isrecomputed and re-compared against the fraud score threshold.Alternatively, the authentication results can be used to weight thepoint values of one or more of the transaction parameters 116 in thefraud multiplier computation and the fraud score is recomputed.

[0051] As the fraud detection system 108 operates, there may be errors(i.e. false positive and false negative responses from the system whichare later determined by the vendor 106 or consumer information provider224). In one embodiment, as these errors occur, the mis-flaggedtransactions 100 may be further reviewed or analyzed, either manually orautomatically, by fraud investigators, to determine why the systemfailed. Where it is determined that a particular transaction parameter116 or SKU is not accounted for or has an unbalanced effect on the frauddetermination process, the databases 308, 310, 312, 314 are adjusted tocorrect the error. Such adjustments include altering point values,defining new or refining existing inter-parameter relationships ordefining additional transaction parameters to be considered.

[0052] Further, the disclosed fraud detection system is capable ofdetecting fraud generally and not just specific instances of fraud suchas a bad check or a stolen credit card. For example, the disclosed frauddetection system detects fraudulent use of coupons or discounts,fraudulent use of insurance for medical, dental or automobile relatedvendors 106 or fraudulent use of prescriptions for pharmaceuticalrelated vendors 106. All of the characteristics of the transaction arebalanced so that factors which are more likely to indicate fraud have alarger impact on the determination but other factors and relationshipsamong factors are still significantly considered.

[0053] In addition, while the above processes, comparisons andcomputations are disclosed as being performed in a particular order, inalternative embodiments the performance order may be different and allorderings are contemplated. For example, in one embodiment, the SKUpoints are computed prior to the computation of the fraud multiplier.

[0054] The disclosed processes, comparisons and computations arepreferably implemented in software as computer programs written in theRPG language. The software and databases are preferably executed on anAS/400 computer system manufactured by IBM Corporation, located inArmonk, N.Y. The computer systems are preferably executing the OS/4004.0 or higher version operating system provided by IBM. The databasesare preferably implemented using the AS/400's Integrated File System.Alternatively, the software and databases are implemented on a mainframecomputer system complying with the IBM 390 architecture. In stillanother embodiment, the software and databases are implemented on anRS/6000 computer system manufactured by IBM Corporation utilizing theUNIX operating system. In still another alternative embodiment, thesoftware and databases are implemented using the Structured QueryLanguage and executed on a computer system having a processor equivalentto a Pentium III or better, manufactured by Intel Corporation, locatedin Santa Clara, Calif. and utilizing the Microsoft Windows NT 4.0Operating System and Microsoft SQL server manufactured by MicrosoftCorporation located in Redmond, Wash. In further embodiments, one ormore of the component parts of the fraud detection system areimplemented directly in hardware. It will be appreciated that theimplementation details will vary depending on the hardware and softwareenvironments of the participating vendors 106, 316, 318 and the consumerinformation provider 224.

[0055] In the first embodiment, most of the fraud processing is externalto the vendor 106 and can therefore be implemented in the singlecomputing environment of the consumer information provider. Thiscontains development of the fraud detection system to a single computingplatform and single programming language, etc. easing development andmaintenance complexity.

[0056] Second Embodiment

[0057]FIGS. 3A and 3B show a second embodiment of the fraud detectionsystem 108. This embodiment differs from the first embodiment only inthe division of processing between the vendor 106 and the consumerinformation provider 446 which may or may not be external to the vendor106, as described above.

[0058] Referring to FIG. 3A, most of the processing remains internal tothe vendor 106, including the computation of the fraud multiplier (Block416), computation of the SKU points (Block 426), and computation of thetotal fraud score (Block 430) as well as the associated databases 418,420, 422, 424, 428, 434 In this embodiment, however, the negativeinformation databases 418, 422 only contain negative informationcollected by or imparted to this particular vendor 106. The secondarychecking that occurs when the fraud score has exceeded the fraud scorethreshold is performed by the consumer information provider 446 (Blocks432, 436). Typically, this secondary checking involves access tofee-based databases (as described above). In one embodiment, thedecision to perform secondary checking by the consumer informationprovider 446 is manually determined after a manual review of thetransaction 100. Alternatively, the secondary checking can beautomatically performed for all transactions 100 whose fraud scoreexceeds the fraud score threshold or the decision to perform secondarychecking can be based on one or more transaction parameters 116 andresultant point values. In yet another alternative embodiment, secondarychecking with the consumer information provider 446 is done for specifictransaction parameters 116 such as the customer, cardholder and ship-toaddresses with subsequent secondary checking of other transactionparameters determined at the discretion of a manual reviewer.

[0059] Referring to FIG. 3B, the consumer information provider 446checks the transaction 100 against negative databases 508, 510 whichcontain negative transaction information from other participatingvendors 106, 512, 514 or sources (Block 506). From this information, itis determined whether or not there is a history of related fraud (Block518). Further secondary checking is performed as described above againstother proprietary, other public and non-public databases to furtherconfirm the fraudulent status of the transaction 100 (Blocks 520, 524,526). The fraud history, if any, and the results of the secondarychecking are returned to the vendor 106 (Block 528).

[0060] Referring back to FIG. 3A, the fraud detection system determinesthe likelihood of fraud based on the total fraud score and the datareturned by the consumer information provider 446. In one embodiment,the fraud score and the data returned by the consumer informationprovider 446 are manually reviewed and reconciled to determine thelikelihood of fraud (Block 440). Alternatively, the data returned by theconsumer information provider 446 and the fraud score are automaticallyreconciled to determine the fraudulent status. For example, the datareturned by the consumer information provider is used to add or subtractpoints from the fraud multiplier and the fraud score is recomputed andre-compared with the fraud threshold. If it is determined that thetransaction 100 is non-fraudulent, the transaction is accepted (Block442). If it is determined that the transaction is fraudulent, furtheraction can be taken as described above (Block 444).

[0061] In addition to the advantages noted above for the firstembodiment, the second embodiment offers easy data management and lowerbandwidth requirements between the vendor 106 and the consumerinformation provider 446. The main databases 418, 420, 422, 424, 428,434 reside internally to the vendor 106 making updates and adjustmentssimpler and faster. Further, the amount of data needed to pass to theconsumer information provider 446 is reduced since the consumerinformation provider 446 performs less of the overall fraud detectionprocess. Further, the second embodiment provides a high reliabilitysystem which is not subject to communications problems between thevendor 106 and the consumer information provider 446. In the event of acommunications failure, the system still detects fraudulent transactions100. Finally, an internal system for detecting fraud operates andresponds faster than a system which relies more heavily on externalprocessing.

[0062] It is therefore intended that the foregoing detailed descriptionbe regarded as illustrative rather than limiting, and that it beunderstood that it is the following claims, including all equivalents,that are intended to define the spirit and scope of this invention.

We claim:
 1. A method for detecting fraudulent transactions between acustomer and a vendor comprising: (a) receiving a plurality oftransaction parameters from said vendor, said plurality of transactionparameters representing at least one transaction of at least onecommodity between said customer and said vendor; (b) computing a firstscore as a function of said at least one commodity; (c) computing asecond score as a function of a first one or more of said plurality oftransaction parameters; (d) computing a fraud score based on said firstand second scores; and (e) indicating to said vendor that said at leastone transaction is fraudulent if said fraud score exceeds a firstpre-determined threshold.
 2. The method of claim 1 further comprising:(f) comparing a second one or more of said plurality of transactionparameters to a positive database; and (g) indicating that said at leastone transaction is non-fraudulent if a match results, said positivedatabase comprising past non-fraudulent transactions known to saidvendor.
 3. The method of claim 2, wherein a subset of (a)-(g) areperformed by said vendor and the remaining are performed by an entityexternal to said vendor.
 4. The method of claim 2, further comprising:(h) adding one or more of said plurality of transaction parameters tosaid positive database if said comparing fails to match and said fraudscore does not exceed said first pre-determined threshold.
 5. The methodof claim 1 further comprising: (f) comparing a second one or more ofsaid plurality of transaction parameters to a negative database; and (g)indicating that said at least one transaction is fraudulent if a matchresults, said negative database comprising known past fraudulenttransactions.
 6. The method of claim 5, wherein a subset of (a)-(g) areperformed by said vendor and the remaining are performed by an entityexternal to said vendor.
 7. The method of claim 5, further comprising:(h) adding one or more of said plurality of transaction parameters tosaid negative database if said fraud score exceeds said firstpre-determined threshold.
 8. The method of claim 1 further comprising:(f) computing a total value of all of said at least one commodity; and(g) indicating that said at least one transaction is non-fraudulent ifsaid total value is less than a second predetermined threshold.
 9. Themethod of claim 8, wherein said second pre-determined threshold isapproximately $100.
 10. The method of claim 8, wherein (g) furthercomprises dynamically adjusting said second pre-determined threshold.11. The method of claim 8, wherein a subset of (a)-(g) are performed bysaid vendor and the remaining are performed by an entity external tosaid vendor.
 12. The method of claim 8, wherein (c) further comprisesadjusting said second score as a function of said total value.
 13. Themethod of claim 8, wherein (e) further comprises adjusting said firstpre-determined threshold as a function of said total value.
 14. Themethod of claim 1 wherein a subset of (a)-(e) are performed by saidvendor and the remaining are performed by an entity external to saidvendor.
 15. The method of claim 1, wherein said at least one commodityis characterized by a likelihood of fraud and further wherein said firstscore is a function of said likelihood.
 16. The method of claim 1,wherein said plurality of transaction parameters are received after saidat least one transaction has been completed.
 17. The method of claim 1,wherein (a)-(e) are completed while said at least one transaction ispending.
 18. The method of claim 1, wherein (b) further comprisesreferencing a database, said database including a plurality ofcommodities and corresponding scores.
 19. The method of claim 1, wherein(c) further comprises a summation function.
 20. The method of claim 1,wherein (d) further comprises referencing a database, said databasecomprising data corresponding to a plurality of statistical data, aplurality of consumer data and a plurality of historical transactiondata, and further wherein said second score is computed as a function ofa pre-determined point value for each of said plurality of transactionparameters and whether said first one or more of said plurality oftransaction parameters is authenticated by said data.
 21. The method ofclaim 20, wherein said pre-determined point value is less than zero. 22.The method of claim 20, further comprising: (f) adjusting said secondscore based on said pre-determined point values of a subset of saidfirst one or more of said plurality of transaction parameters.
 23. Themethod of claim 1, wherein (e) further comprises adjusting said firstpre-determined threshold as a function of said second score.
 24. Themethod of claim 1, wherein (d) further comprises a summation function.25. The method of claim 1, wherein (e) further comprises multiplyingsaid first score by said second score.
 26. The method of claim 1,wherein said vendor is a catalog based merchant.
 27. The method of claim1, wherein said vendor is an electronic commerce based merchant.
 28. Themethod of claim 1, wherein said vendor is a store based retail merchant.29. A fraud detection processor comprising: a receiver operative toreceive a plurality of transaction parameters from a vendor, saidplurality of transaction parameters representing at least onetransaction of one or more commodities between a customer and saidvendor; a first score processor coupled with said receiver and operativeto compute a first score as a function of each of said one or morecommodities; a second score processor coupled with said receiver andoperative to compute a second score as a function of each of a first oneor more of said plurality of transaction parameters; a fraud scoreprocessor coupled with said first and second score processors andoperative to compute a fraud score as a function of said first andsecond scores; fraud determination logic coupled with said fraud scoreprocessor and operative to compute a determination of whether said atleast one transaction is fraudulent as a function of a comparison ofsaid fraud score and a first pre-determined threshold and furtheroperative to indicate said determination to said vendor.
 30. The frauddetection processor of claim 29 further comprising: a positive databasecomprising past non-fraudulent transactions known to said vendor; and aparameter processor coupled with said receiver and said frauddetermination logic and operative to compare a second one or more ofsaid plurality of transaction parameters to said positive database andindicate a result of said comparison to said fraud determination logic;wherein said fraud determination logic is further operative to determinethat said at least one transaction is not fraudulent when said parameterprocessor indicates a match result.
 31. The fraud detection processor ofclaim 30, wherein said parameter processor is further operative to addone or more said plurality of transaction parameters to said positivedatabase if said comparison fails to match and said fraud determinationlogic determines that said at least one transaction is non-fraudulent.32. The fraud detection processor of claim 29 further comprising: anegative database comprising data related to known past fraudulenttransactions; and a parameter processor coupled with said receiver andsaid fraud determination logic and operative to compare a second one ormore of said plurality of transaction parameters to said negativedatabase and indicate a result of said comparison to said frauddetermination logic; wherein said fraud determination logic is furtheroperative to determine that said at least one transaction is fraudulentwhen said parameter processor indicates a match result.
 33. The frauddetection processor of claim 32, wherein said parameter processor isfurther operative to add one or more of said plurality of transactionparameters to said negative database if said comparison fails to matchand said fraud determination logic determines that said at least onetransaction is fraudulent.
 34. The fraud detection processor of claim29, further comprising a valuation processor coupled with said receiverand fraud determination logic and operative to compute a total value ofall of said at least one commodity and indicate to said frauddetermination logic if said total value is less than a secondpre-determined threshold; wherein said fraud determination logic isfurther operative to determine that said at least one transaction isnon-fraudulent when said valuation processor indicates that said totalvalue is less than said second pre-determined threshold.
 35. The frauddetection processor of claim 34, wherein said second pre-determinedthreshold is approximately $100.
 36. The fraud detection processor ofclaim 34, wherein said second pre-determined threshold is dynamic. 37.The fraud detection processor of claim 34, wherein said valuationprocessor is further coupled with said second score processor andfurther wherein said second score processor is further operative toadjust said second score based upon said total value.
 38. The frauddetection processor of claim 34, wherein said fraud determination logicis further operative to adjust said first pre-determined threshold as afunction of said total value.
 39. The fraud detection processor of claim29, wherein said at least one commodity is characterized by aprobability of fraud and further wherein said first score is as afunction of said probability.
 40. The fraud detection processor of claim29, wherein said plurality of transaction parameters are received aftersaid at least one transaction has been completed.
 41. The frauddetection processor of claim 29, wherein said fraud determination logicis further operative to make-said determination while said at least onetransaction is pending.
 42. The fraud detection processor of claim 29,wherein said first score processor further comprises a commodityreference database, said commodity reference database including aplurality of commodities and corresponding scores wherein said scoresare a function of the probability of fraudulent activity related to acorresponding commodity.
 43. The fraud detection processor of claim 29,wherein said second score processor further comprises a transactionalreference database, said transactional reference database comprisingdata corresponding to a plurality of statistical data, a plurality ofconsumer data and a plurality of historical transaction data, andfurther wherein said second score processor is further operative tocompute said second score as a function of a pre-determined point valuefor each of said plurality of transaction parameters and whether saidfirst one or more of said plurality of transaction parameters isauthenticated by said data in said transactional reference database. 44.The fraud detection processor of claim 43, wherein said pre-determinedpoint value is less than zero.
 45. The fraud detection processor ofclaim 43, wherein said second score processor is further operative toadjust said second score as a function of said pre-determined pointvalues of a sub-set of said plurality of transaction parameters.
 46. Thefraud detection processor of claim 29, wherein said fraud determinationlogic is further operative to adjust said first pre-determined thresholdbased on said second score.
 47. The fraud detection processor of claim29, wherein said vendor is a catalog based merchant.
 48. The frauddetection processor of claim 29, wherein said vendor is an electroniccommerce based merchant.
 49. The fraud detection processor of claim 29,wherein said vendor is a store based retail merchant.
 50. A computerimplemented system for detecting fraudulent transactions between acustomer and a vendor comprising: a positive database comprising datarepresenting past non-fraudulent transactions known to said vendor; anegative database comprising data representing past known fraudulenttransactions; one or more transaction databases comprising consumer andgeographic transaction information; a commodity database comprising datarepresenting valuation and propensity to incite fraudulent activity fora plurality of commodities; transaction logic operative to receive atransaction of a commodity from a vendor and decompose said transactioninto a plurality of transaction parameters; result logic operative tosend an indication to said vendor whether said transaction is fraudulentand non-fraudulent; valuation logic coupled with said transaction logic,said result logic and said commodity database and operative to computethe total value of said transaction and cause said result logic toindicate that said transaction is non-fraudulent if said total value isless than a first pre-determined threshold; comparison logic coupledwith said transaction logic, said result logic and said positivedatabase and operative to compare said transaction with said positivedatabase and cause said result logic to indicate that said transactionis non-fraudulent if said transaction matches in said positive database;and fraud logic coupled with said transaction logic, said result logicand said negative database, said one or more transaction databases andsaid commodity database and operative to compute a first score as afunction of said past fraudulent history and said propensity to incitefraudulent activity of said commodity, a second score as a function ofthe authenticity of said plurality of transaction parameters and a fraudscore as a function of said first and second scores, said fraud logicbeing further operative to cause said result logic to indicate that saidtransaction is fraudulent if said fraud score exceeds a secondpre-determined threshold.
 51. The system of claim 50, wherein one ormore of said positive database, said negative database, said one or moretransaction databases, said commodity database, said transaction logic,said result logic, said valuation logic, said comparison logic and saidfraud logic operates on a computer system internal to said vendor andthe remaining operates on a computer system external to said vendor,said internal and external computer systems in communication with eachother.
 52. The system of claim 50, wherein said fraud logic is furthercoupled with said valuation logic and further wherein said second scoreis dynamically adjusted as a function of said total value.
 53. Thesystem of claim 50, wherein said fraud logic is further coupled withsaid valuation logic and further wherein said second predeterminedthreshold is dynamically adjusted as a function of said total value. 54.The system of claim 50, wherein said system is operative to process saidtransaction in real time.
 55. The system of claim 50, wherein saidsystem is operative to batch process said transaction.